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(57) Abstract: A database system stores data relating to media objects for use in media presentations. The database system includes a 
primary metadata table containing metadata records and a supplementary metadata table containing supplementary metadata records, 
each supplementary metadata record being linked to a metadata record and specifying an additional attribute for an object type spec- 
ified in the linked metadata record. The database further includes a primary content data table containing content data records and 
a supplementary content data table containing supplementary content data records, each supplementary content data record being 
linked to a supplementary metadata record and to a content data record. The content data record is linked to the metadata record as 
a specific instance of the object type defined in the metadata record, and the supplementary content data record contains a value for 
the additional attribute specified in the linked supplementary metadata data record which is applicable to the specific instance of the 
object type specified in the linked metadata record. An object type link table links together records in the primary metadata table, 
and a content data link table links together records in the primary content data table. An information retrieval system analyses the 
primary metadata table, the primary content data table, the supplementary metadata table, the supplementary data table, the object 
type link table and the content data link table and provides, for a selected instance of an object, information about that object's 
attributes and relationships with other objects in a hierarchical form. 
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Database System, Particularly for Multimedia Objects 

The present invention relates to a database system which is particularly useful in the 
field of storing and managing multimedia objects such as text, sounds and images for 
5 use in multimedia presentations. However, the principles of the invention are 
applicable to other environments in which a database system is required. The 
invention is particularly concerned with a simple and extendible system for storing 
data objects without frequently changing the database structure by adding new tables 
or modifying table structures. 

10 

The media industry faces ever increasing challenges, sj/ch as the desirability of 
providing a solution for the convergence of a broadband rich media internet 
experience and live television production and delivery, the internet demands of real- 
time news, video on demand, user personalization, and continuing creative additions 
15 to initial systems. 

Delivery of interactive media, which describe real events in the real world in real- 
time, requires the ability to quickly acquire, store, edit, and composite live and other 
descriptive media by a large team of editors, artists, and producers. The data 

20 infrastructure necessary to address these and other related demands should satisfy 
various requirements. Means should be provided to describe any media or other data 
item. This encapsulation, or object, must provide opportunities to include attributes 
such as rights, versioning, attachment to composite objects, and any other descriptive 
characterization of itself and related data and processes. The system should be flexible 

25 and able to adapt to rapid changes, and should be able to scale sufficiently to support 
the vast requirements of a media rich world. 

Viewed from one aspect, the present invention provides a database system which 
stores data relating to media objects for use in media presentations, the database 
30 system including a table containing metadata records specifying object types 
including hierarchical organisation object types and media object types, and the 
database also including a table containing content data records, each content data 
record being linked to a metadata record and containing at least one value for a 
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parameter applicable to a specific instance of the object type specified in the linked 
metadata record. 



Preferably, the database system in accordance with the invention includes a primary 
5 metadata table containing metadata records and a supplementary metadata table 
containing supplementary metadata records, each supplementary metadata record 
being linked to a metadata record and specifying an additional attribute for the object 
type specified in the linked metadata record, and the database further includes a 
primary content data table containing content data records and a supplementary 

10 content data table containing supplementary content data records, each supplementary 
content data record being linked to a supplementary metadata record and to a content 
data record, the content data record being linked to the metadata record as a specific 
instance of the object type defined in the metadata record, and wherein the 
supplementary content data record contains a value for the additional attribute 

1 5 specified in the linked supplementary metadata data record which is applicable to the 
specific instance of the object type specified in the linked metadata record. 

Preferably, in the database system in accordance with the invention, links may be 
established between metadata records and preferably links may be established 
20 between content data records. 



Such a system makes it possible to model an organization's aggregate information 
such that it can be fully described in a flexible, extendible and scalable manner. The 
system makes it possible to establish one or more distinct hierarchies, each of which 
25 represent a recursive decomposition of the organization's abstract information model. 
This decomposition provides the opportunity to reduce the information model to it's 
smallest parts. Each of these parts can then be fully described in terms of content and 
the relationship with other parts in the hierarchy. 

30 In essence the database schema is such that the metadata records describe an 

organization's information model, and the data records hold the actual data content 
itself. The metadata records define objects that are concerned with the hierarchical 
organization of the data, i.e. categories such as subjects (sports, news, entertainment) 
and stories within those subjects. The metadata records also define objects that will be 
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used for the stories, such as text, images, audio and video. The content data records 
define specific instances of these objects. Supplementary metadata records enable 
additional attributes of an object to be defined, and supplementary content data 
records enable values to be stored for specific instances of the object. 

5 

Changes to the system can be made by making changes to the metadata and 
supplementary metadata records. There is no need to modify the basic table structure, 
and so changes can be implemented quickly and easily without interrupting use of the 
system. 

10 

Whilst the system is of particular use in managing media objects, it can be used in 
other environments. It can be used for general office, staff and customer management 
in a media organisation or in any other type of organisation, and could be adapted for 
specialist applications such as keeping records of patents and trade marks in an 
15 attorney's office. 

The database system of the present invention can be operated on data processing 
means such as a server running a database engine such as Microsoft's SQL Server 
(trade mark) under a server operating system such as Microsoft's Windows NT or 
20 2000 (trade marks). 

Viewed from another aspect, the present invention provides a database system for 
storing information relating to a number of objects of various object types, 
comprising: a first metadata table containing records, each first metadata table record 

25 specifying an available object type and defining a set of attributes relevant to the 
object type; a first content table containing records, each first content table record 
being linked to a record in the first metadata table and containing data pertaining to an 
object which is a specific instance of the object type specified in the linked record in 
the first metadata table, the data including a value for at least one attribute defined in 

30 the linked record in the first metadata table; a second metadata table containing 
records, each second metadata table record being linked to a record in the first 
metadata table and defining an additional attribute relevant to the object type specified 
in the linked record in the first metadata table; and a second content table containing 
records, each second content table record being linked to a record in the first content 
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table and to a record in the second metadata table and containing a data value for the 
additional attribute defined in the linked record in the second metadata table which 
applies to the specific instance of the object in the linked record in the first content 
table. 

5 

Viewed from another aspect, the present invention provides a method for acquiring 
and storing media objects and for making the media objects available from a 
hierarchical structure for use in media presentations, comprising the steps of : 
establishing a database for storing information relating to a number of objects of 

10 various object types, the database comprising a first metadata table, a first content 
table, a second metadata table and a second content table; entering into the first 
metadata table object type records, each specifying an object type and defining at least 
one attribute relevant to the object type; in respect of at least one object type record in 
the first metadata table, entering into the second metadata table a record linked to the 

1 5 object type record and defining an additional attribute relevant to the object type 
specified in the linked record in the first metadata table; acquiring data relating to 
media objects, each of which is a specific instance of an object type specified in the 
linked record in the first metadata table; in respect of each media object entering into 
the first content table a record linked to the associated object type record in the first 

20 metadata table and containing data pertaining to the media object, the data including a 
value for at least one attribute defined in the linked record in the first metadata table; 
and in respect of at least one media object entering into the second content table a 
record linked to the media object record in the first content table and to the associated 
object type record in the second metadata table and containing a data value for the 

25 additional attribute defined in the linked record in the second metadata table which 
applies to the media object in the linked record in the first content table; the method 
including the further step of providing an information retrieval system running on 
data processing means which analyses the first metadata table, the first content data 
table, the second metadata table and the second data table, and provides, for a selected 

30 instance of an object, information about that object's attributes and relationships with 
other objects in a hierarchical form. 

In order to use the system described above there should preferably be an interface 
which can analyse the first metadata table, the first content table, the second metadata 
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table and the second content table and provide, for a selected object in the first 
metadata table, information about attributes specified in the first and second metadata 
table for the object type of which the selected object is a specific instance, and values 
for those attributes which are stored in the first and second content tables and are 
5 associated with the selected object. 

In a practical arrangement there would be an application program interface (API) that 
manages the database and provides an efficient and simple way of accessing objects 
by abstracting the complexity of the schema. There would preferably be a database 
10 tool for use by administrators to define and update metadata, including object types, 
attributes and rules. There would preferably be a back end application to maintain the 
actual data content, such as instances of objects, their attributes and relationships. 
There would also be a front end application for disseminating data to a user, for 
example by means of a web site. 

15 

A database system in accordance with the invention enables complex systems to be 
created for handling media objects. Thus, there can be provided a system for 
managing components of a media presentation, comprising the steps of storing a 
component in a plurality of formats, using the database system to establish an object 

20 representative of the component and establishing a link between the object and the 
stored plurality of formats, making the object available for selection to be included in 
the presentation, and enabling selection of at least one of the plurality of formats when 
the object is to be used in the presentation. Thus, a video clip for example could be 
stored as an MPEG file, as a streaming video file, or as a tape having a physical 

25 storage location for example, and the system will link the three objects to the video 
clip object. Such a system for handling objects in different formats is inventive in its 
own right and can be implemented with other, conventional database systems. 

The system makes it possible to acquire material from many different sources and to 
30 create a large database of objects available rapidly to designers of different 

presentations, whether they are television broadcasts, web broadcasts, web pages, or 
hard copy publications. Handing material in a system intended to enable the rapid 
deployment of text and images creates various problems. One of these is the need to 
obtain copyright clearance or other permissions. Material may be obtained from many 
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different sources, such as commercial suppliers of images or of material for broadcast, 
news agencies, web sites of other parties, newspapers, and so forth. Thus the present 
invention can be used to provide a system for managing components for inclusion in 
media presentations, in which a component is acquired and stored, an entry 
5 identifying the component is made in the database system, the entry including 

information indicating whether permission has been granted for use of the component, 
and inclusion of the component in a presentation is inhibited until the entry in the 
database indicates that permission has been granted. Such a system for tracking 
permissions is inventive in its own right and can be implemented with other, 
1 0 conventional database systems. 

In some cases, the component will not be made available to a designer until 
permission has been obtained. In others, the designer may be able to identify the 
nature of the component, but will not be able to include it in presentations until 
15 permission has been obtained. In others, the component may be available for inclusion 
in the presentation at the design stage, but the presentation may not be published until 
permission has be obtained. 

The system may be combined with other aspects of the invention, so that the 
20 component may be stored in various formats and presented as an object. The system 
may be such that a component cannot be converted into additional formats until 
permission has been obtained. 

In a development of the system for recording permissions, the database system may 
25 store information relating to the source of the component such as a picture library, 
news agency and so forth. The system may also store information about permission 
when received, such as a time limit, or the number of times that the component may 
be used, or the various formats allowable, or the type of publications in which the 
component may be used. These developments will make it easier to control the use of 
30 large amounts of material acquired on a world wide basis. 

In another development, there may be arrangements set up to produce an automatic 
request for permission by e-mail, fax or any other means if it is desired to use a 
component. This could, for example, be prompted by a designer selecting an object 
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that it is desired to include in a publication. There may also be a system for a supplier 
of components to respond to a request so that permission is automatically recorded, 
and even any management or financial matters dealt with. 

5 The versatility of the database system in accordance with the invention is such that it 
can be used in contexts other than the production of media presentations as such, 
including tracking copyrights as explained above, and other administrative functions. 

Other aspects of the present invention include a computer software product containing 
10 instructions which when carried out on data processing apparatus will create a 
database system as set out above; an information retrieval system for use with the 
database system, the information retrieval system having components arranged to 
analyse the first metadata table, the first content table, the second metadata table and 
the second content table as set out above; a computer software product containing 
1 5 instructions which when carried out on data processing apparatus will create such an 
information retrieval system for displaying in a hierarchical structure information 
relating to objects; a method of creating a media presentation by assembling objects 
stored in the database system; and a media presentation so created. 

20 The database system may be held on a single server on a plurality of servers which 
may be at the same or different locations. Client software for use in accessing the 
system may be provided in any suitable form, for example on physical media such as 
a disk or tape, or as signals provided from a remote location, for example over a 
network such as the Internet. The software may be in a form ready for use or in an 

25 encoded or compressed form. The client software may be run locally on a client 

console such as a personal computer or may be run on a remote application server. In 
a preferred arrangement, software for use in accessing the database is run on a remote 
application server to which users can be connected using browser technology over the 
Internet or over a private network. 

30 

Some embodiments of the invention will now be described by way of example and 
with reference to the accompanying drawings, in which: 
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Figure 1 is a schematic overview of a database system in accordance with the 
invention; 

Figure 2 is a conceptual class diagram of some core components of the database. 

5 

Figure 3, is a class diagram of a story object in an object store; 

Figure 4 is an instance diagram of a story object in an object store; 

1 0 Figure 5 is a class diagram of subject and image objects in an object store; 

Figure 6 is a class diagram of the base classes and instances for images with 
attributes; 

15 Figure 7 is an example of a class diagram of subject, story, and image objects in an 
object store; 

Figure 8 is an instance diagram showing the relationship between a story and an 
image; and 

20 

Figure 9 is a class diagram of data feed objects. 

With reference to Figure 1, the heart of the system in accordance with the invention is 
a database which is refen-ed to as the "Object Store". The Object Store consists of a 
25 database as defined in an Object Store Schema, which supports the various 

applications that interface with it, through an Object Store Application Program 
Interface (API). These components are shown in Figure 1 and comprise Front End 
Applications, Back End Applications and an Object Store Tool. 

30 The Object Store schema is a unique object-relational schema that is defined over a 
traditional relational database. The Object Store schema consists of two main sets of 
tables, namely tables that describe the organization's information model (meta tables), 
and tables that hold the actual information content itself (content tables). Figure 2 is a 
conceptual UML (Unified Modelling Language) class diagram of the Object Store. 

8 
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This simple UML diagram (not all fields are shown) represents the core Object Store 
tables. Its simplicity is apparent, but its flexibility may not be. It acts as a virtual 
database within a normal relational database management system (RDBMS), allowing 
a complex virtual schema to be contained within it. 

5 

The meta tables (prefixed with metaj hold the metadata of the information model, 
i.e. they hold the data that fully describes the way the information model can be 
decomposed into various data objects. This is achieved by ensuring that each 
decomposed object is defined in terms of its content and how it relates to the other 
10 objects in the decomposition hierarchy. This definition describes both the structure of 
the object, namely its attributes and relationships, as well as its behaviour, namely the 
rules for creating and modifying the object. 

In Object Oriented terms each of these definitions can be seen as Base Classes. 
1 5 For example, in the context of designing a web page in a web context the objects that 
may be defined are stories, images and so forth. Object Base Class definitions in the 
meta tables will be referred to as "the metadata" in this description where appropriate. 

In the figures, PK denotes a primary key, i.e. a field or combination of fields whose 
20 values uniquely identify a row or record in the table. The primary key(s) will have a 
unique value for each record or row in the table. FK denotes a foreign key, i.e. a field 
or combination of fields in one table whose value(s) matches the primary key(s) in 
another table. 

25 Table 1 describes the core meta database tables. 



Table 1 



Table 


Description 


meta_item 


The metajtem table holds the Base Class definitions of all 
Objects in the Object Store. For example, in a web context the 
Objects that may be defined are Stories, Images, etc.. 
This table primarily defines the Object's name and its position in 
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the hierarchy of the defined Objects. This allows the 
decomposition of the aggregate information to be described in 
terms of the Object names and their hierarchical structure. There 
is the ability to link an Object to a parent Object. When a new 
Object is required, it is added to metajitem and, if required, 
linked to an appropriate parent. 


meta_item_link 


The meta_item_link table holds the definition of all relationships 
required between Objects defined in the Object Store. 
For example, in a web context it would be possible to link a Story 
to other related Stories according to a relationship defined in this 
table. This is achieved by inserting a link record between the 
relevant meta_item records. In this example the Story Base Class 
definition would be related back to itself. To allow a Story to 
relate other objects in the Object Store, a meta_itein_link record 
would be created linking the Story Base Class to the Base Class 
definition of the relevant Object. 


metajQeld 


The meta_field table is used to define attributes (fields) of an 
Base Class defined in metajtem. Thus, it is used to extend the 
Base Class attributes of an Object defined in metajtem, by 
adding additional attributes. For example, the text attribute for a 
Story Object would be defined in metajField, as would a tape 
label attribute for a Tape Object. 

The Object Store API is designed to automatically retrieve all 
metaJTield attributes for an Object. 

Every meta_field item (Object attribute) can be defined as 
mandatory, with a default value, etc. The data type can also be 
defined, e.g. integer, character, etc. 



The content tables (prefixed with c_) hold the actual organizational information itself. 
Using the web example above, these tables would contain the actual written stories 
themselves and the images that go with them. 
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In object oriented terms the content tables hold the instances of objects (i.e. the 
organisation's stories, images etc.) that inherit their structure and behaviour from their 
Base Classes as defined in the Meta Tables. Instances of the Object Base Classes that 
5 are stored in the content tables will be referred to as "instances" in this description 
where appropriate. 

Table 2 describes the core content database tables. 
10 Table 2 



Table 


Description 


cjtem 


Whereas metajtem defines the Object Base Class definition, c_item 
contains an instance of that Object Base Class definition. 


c_itemjink 


This stores the relationships between Object instances for 
relationships defined in metajtemjink. 


c_field 


Object attributes are defined in meta_field with the actual values 
stored in cjfield. In other words, the values in c_field are instances 
of the defined attributes, cjield attributes are linked to an Object 
instance in c_item. 



Thus, the meta tables are containers for serialization of a static class model, and the 
content tables are containers for serialization of simple object instances and their 
15 relationships. 

One schema feature that is strongly encouraged by the Object Store is a hierarchical 
object structure. In a simple implementation, the Object Store provides a hierarchy 
for both classes and their object instances. Hierarchical design is becoming 
20 increasingly popular, particularly in databases supporting web sites, because of its 
expressiveness and flexibility. The model also allows for relationships to be created 
between objects. 
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As shown in Figure 1 , the Object Store is "wrapped" by the Object Store API 
(Application Program Interface). The API is a function call layer that manages the 
database access through a set of routines that, for example, call database stored 
procedures to insert, modify, retrieve, and delete Objects. This provides an efficient 
5 and simple method of accessing Objects in the Object Store by abstracting the 
complexity of the schema. To access the hierarchical object structure in the Object 
Store, stored procedures like the following are called through the Object Store API 
layer: 

10 Getjtem 

GetJttem__Children 
GetJttemJParent 

The Object Store Tool is an application used by Object Store Administrators to define 
1 5 and update metadata, including object types, attributes and rules. Modifications to the 
metadata are immediately available for use and this application would usually only 
update the meta tables (prefixed with metaj. 

Front end applications are those that would disseminate the content data to the end 
20 user, for example, a web site. These applications would usually access the content 
tables, and would also usually take advantage of the metadata defined in the meta 
tables describing the objects and attributes. 

Back end applications are those necessary to maintain actual content information, i.e. 

25 instances of the objects, their attributes, relationships, etc. These applications would 
usually only update the content tables and would need knowledge of the metadata 
defined in the meta tables. With this knowledge it is possible to design a single tool 
that can generically manage all the content data in the Object Store through an 
understanding of the objects, their rules, relationships, field validation, default values, 

30 and so forth. 

Using a traditional database solution, changes to the metadata, e.g. additional objects 
or attributes changes to the schema would normally result in database changes and 
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changes to the back end applications. A system using the Object Store requires no 
changes to the database structure and few or no changes to these applications. 

In an example of how the database system may be used, consideration will be given to 
5 adding a Story with some associated media to the Object Store. In this example, the 
following steps will be followed. Note that there is some flexibility in the order of the 
steps. The only constraint is that an object must be defined before it can be used, i.e. 
the object must have a base class definition in the meta tables. 

10 Define a Story 

Add an instance of a Story 

Extend the definition of an Image 

Add an instance of an Image 

Define a relationship between an Image and a Story 
1 5 Add an instance of a relationship between an Image and a Story 

In this example it is assumed that stories on a web site are grouped by subject area 
such as Education, Sport and so forth. In order to achieve this, it is decided that the 
system must hold at least the following data: 

20 

A subject with a title. 

A story with a title and story text. 

Knowledge of which subject the story belongs to. 

25 Using a traditional database solution, it would be necessary to add two new tables to 
the database schema and a relationship between them. These changes to the schema 
would result in a knock on effect and would also require extensive changes to any 
database replication mechanism, the back end tools used to update the content data, 
and the front end tools which access this data, e.g. new stored procedures etc. Using 

30 the Object Store approach, there is no impact on the database schema at all. This is 
because changes to the existing data structure are defined in the metadata of the 
Object Store, and not in the database schema itself. The metadata of the Object Store 
represents the virtual schema. A physical database schema does not exist and is 
derived purely from interpreting the metadata in the Object Store. This is where the 

13 
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rationale and advantages behind using the Object Store approach lies. As a result, 
there is no impact on any database replication mechanism that may be in place and 
there will be no (or very little changes) required to any generic back end applications 
that have been implemented either. The users will be able to immediately create and 
5 maintain stories within chosen subjects through their existing tools. Front end 
applications will benefit from the Object Store API and no additional functions to 
access this new data would need to be implemented. 

To implement this structure using the Object Store, the metadata would be defined as 
10 shown in Figure 3, which is a UML Class Diagram of the Story Object in the Object 
Store. Each metajtem has: 

a unique id 

a reference to the id of its parent in the hierarchy (for example the id of subject) 
15 a name (e.g. Story) 

an optional description 

The first metajtem is in respect of the subject, and the second is in respect of the 
story. 

20 

A Story Text field is defined in the metajSeld table and this has: 
a unique field id 

a reference to the meta_ item it is an attribute of 
25 a name (e.g. Story Text) 

additional information to assist the back end tool such as whether it is mandatory, has 
a default value etc. 

It will be seen that setting up a hierarchy for stories, which are arranged under subject 
30 categories and themselves have associated objects such as text or images, requires no 
change to the database structure. In the metajtem table, two new records are made 
The first is for the subject object, and the second is for the story object. These are 
linked so that a story is organised under a subject. In the metajield table, new entries 
are made for text and any other objects such as images. 

14 
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Having defined a Story in the metadata of the Object store, it is now possible to add 
an instance of a Story, i.e. add an actual Story to the content tables of the Object 
Store, with story text and within a specific subject area. 

5 The UML Instance Diagram of the Story Object in the Object Store appears in Figure 
4. On the left are the metadata definitions i.e. Subject, Story, and Text and on the right 
the corresponding data in cjtem and cjield. These establish that the subject is sport, 
that the story is " Sampras wins at French Open" and that there is a story text. 

10 A further example concerns how to extend the definition of an Image. Assuming that 
there is a previously defined Image object in the Object Store which, for example, is 
also child of a Subject, this example shows how an additional field such as a caption 
could be added to the Image object. In object terms an additional attribute will be 
added to the Base Class of the Image Object. 

15 

With a traditional solution it would be necessary to alter the physical database schema 
as well as attending to the resultant problems in any replication mechanism and 
interfaces. With the Object Store approach this field can be added "on the fly" with no 
changes required to any replication mechanism and very few (if any changes) required 

20 in the interfaces. Figure 5 is a UML Class Diagram of the Subject and Image Objects 
in the Object Store with a caption field, and other fields, linked to the Image Object. 
This shows how the Image metajtem is linked under the Subject metajtem. To 
accommodate various attributes of an image, additional fields have been defined in 
the meta_field table. The are for the image filename (i.e. where the image file can be 

25 located), the image width and height, and the image caption. If previously an image 
caption had not existed, it would simply be necessary to add a new record in the 
meta_field table. 

To add an image, or to update its data if for example a caption has been added, data is 
30 added to the content tables. The resultant arrangement is shown in Figure 6 which is 
the UML Class Diagram of the Base Classes and instances of these. On the left are the 
metadata definitions for an Image and on the right the actual Image data as stored in 
cjtem and cjSeld. In this case, data is stored showing that under the subject Sport, 
there is an image called "Sampras Wins". The file in this instance is "sampras.jpg", 
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with a width of 50, a height of 1 00 and a caption which for the purposes of this 
example is given as "Image caption text". 

To be able to create a relationship between an Image and a Story, with a traditional 
5 database approach unless such a relationship was already part of the schema it would 
be necessary to alter the physical database schema and attend to all the problems that 
would result in the replication and back end tools. With the Object Store approach this 
relationship is defined in the metajtemjink table of the Object Store and results in 
minimal impact on surrounding systems. 

10 

Figure 7 is an example of UML Class Diagram of the Subject, Story, and Image 
Objects in the Object Store with a relationship between a Story and an Image. In the 
meta_itemjink table a new entry has been made, linking the Story and Image 
metaitems by their id's. Having fully defined a Story and an Image, and defined a 
1 5 relationship between the two in the Object Store, it is now possible to create a 

relationship between an actual story and an image by adding a c_itemjink record. 
Figure 8 is the UML Instance Diagram showing the added relationship between the 
Story and the Image. Thus, the "Sampras Wins" image is not only linked to the Sport 
subject but also to the specific story "Sampras Wins at French Open". 

20 

A further example concerns handling data feed, i.e. the importation of data from 
various sources for the creation of e.g. a web page. The overall requirement is to 
import data from various organisations via various mechanisms and in varying 
formats, to process the data, and to store it in the database in a predefined format. For 
25 this there would preferably be a generic Import Engine which would be able to handle 
the diverse formats from the various organisations in a flexible and data driven way. It 
would be necessary to hold information relating to: 

the provider of the data 
30 the source parameters of the data 
the format of the data 
the output format required 

the data import and manipulation process to be used 
the frequency of the required import 
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and finally to store the imported data related to the source. 

Figure 9 is the UML Class Diagram of the Data Feed Objects in the Object Store. 

As will be seen, arranged under "Data Provider" is the Data Source File object. This is 
linked to four metajield records for location, type, process engine and refresh rate. It 
is also linked to the data field mapping meta_item, which is itself linked to meta_field 
records for input position, type and output position. The Data Source File object is 
also linked to .the DataSet metajtem. This is linked to a metajield record for Run 
Date, and to a meta_item Dataltem which is linked to a meta_field for 
Data. The DataSet object is used as a "folder" object as a container for other data 
objects. This additional structure would be beneficial in a generic back end tool in 
order to group the data and simplify the user's view of the data in the user interface. 

In a practical embodiment, further data tables will be required. For example, the 
following tables may be used. 

S JJSER - Contains a list of all the users including their name, network login name, 
department, etc. 

SJUSER_GROUPS - Contains a list of all user groups, such as User, Administrator, 
Sub-Editor, etc. 

SLJLFSERGRP - Links a user with a user group. 

S_APPLICATION - Contains a list of all the applications used and the code that 
needs to be run when the application loads, such as File Manager, User Manager, 
Copyright, etc. 

SL_APP_USERGRP - Links a user group with an application. 

GJJYSTEMJ3ETTINGS - Used to store certain constants, such as where the system 
stores real media files, etc. 
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META JTEM - As explained above, this is a core system table. Everything in the 
system has an associated meta item. A story has meta item and so does a video, and 
folders are meta items as are categories. 

5 

META_FIELD - This is also a core system table. Typically a meta item will require 
fields to be collected for it. These are done by adding a meta field which links back to 
the meta item. In a story the text is stored in a field that is defined for the meta item 
of a story in a meta field. Videos have fields such as sub title, duration, etc. The way 

1 0 the system is arranged, it is possible to simply add a field to a meta item and the code 
will automatically pick this up and allow users to gather information on it. For each 
meta field it is possible to define whether it is mandatory, give it a default value, 
maximum width, etc. It is also possible to define what type it is, integer, character, etc 
and how its control type should be displayed on a screen including which tab (page) it 

1 5 should be shown on. 

META_CONTROL_TYPE - This contains a list of meta control type that can be 
given to a meta item. For each of these control types there is some code stored that 
gets executed when the field is displayed. This code is written once and can be used 

20 on any meta field. Every meta field has a control type. This defines how it is 

displayed and what checks are done on it. Control types include Text Field, Hidden, to 
more complicated control types such as drag and drop, duration, combo box, drag 
drop video, upload and preview. This means that there is the ability to add a new meta 
field to a meta item with a certain meta control type that will allow users to upload 

25 videos, or use a drag and drop crop thumbnail image without it being necessary to 
write a single line of new code. 

METAJFIELDJTYPE - Contains a list of what type of data is being collected, such as 
text, numeric, etc. 

30 

NffiTA JTEMJPAGE - Every meta item field is given a meta item page. This tells the 
system which page (tab) the field should be shown on. For example it could be 
decided that a thumbnail on a video is displayed on the third tab. Stored in the page is 
which graphic to display for the tab, and its width. 
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META_ACTION - Every meta item can have zero or more actions (add, copy, delete, 
etc). These are added to each meta item allowing an administrator to define what users 
are allowed to do on each item. 

5 

METAJTEMJLINK - There is the ability to link a meta item to another meta item. 
This allows the system to relate a meta item, giving a one to many relationship. If a 
meta item is related back to the original meta item or to itself it is possible to have a 
many to many relationship. For example, a Web Block could be linked (related) to 
1 0 itself, Polls, URL Links, and Forums. 

SL_ACnONJJSERGRP - Links a meta action to a user group. For example, only 
certain groups can delete certain assets 

1 5 C JTEM - As explained above, this is a core system table. The metajtem table 
defines the data collected and the cjtem table stores the actual data. For instance 
every video, story, category, image, running order, script, etc has a cjtem record. 
This gives it an item id, title, description, copyright information, when it was created, 
modified, etc. 

20 

Stored in every cjtem record is the metajtem id so that it is known from looking at 
an item that it is a web block, video, category, etc. It also stores the item id of the 
parent cjtem so that it is known that a story belongs to a particular web block, etc. 

25 CJFIELD - This is also a core system table. Whereas the cjtem table stores the data 
defined in the metajtem table, stored in the cjield table is the data that is defined in 
the metajfield table. The c_field record is linked to the cjtem. 

CJTTEMJLINK - This stores the actual links between the items as defined in the 
30 metajtem Jink table. For example, the metajtem Jink table will enable a user to 
link stories together. 

It will thus be seen that the Object Store is a simple, powerful and flexible way to 
store complex data. It is particularly suitable to applications that utilize object- 
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oriented techniques in the middle-tier, when the database is replicated and when rapid 
development is required. The data model employed by the Object Store is flexible and 
yet powerful Applications built on top of the Object Store can be developed very 
quickly and faster than is possible if a conventional database schema is adopted. 

5 

To add a new type of object to a conventional relational database, a new table would 
need to be added to the database schema. Applications harnessing the power of the 
Object Store only need to add a new object to the meta tables using the Object Store 
Tool. For an application that requires new objects to be added regularly, this provides 
10 an extremely flexible, extensible method of extending the system. When an object is 
added to the Object Store, database replication moves the virtual schema changes as 
data to remote sites without administrative intervention. 
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CLAIMS 



1 . A database system which stores data relating to media objects for use in media 
presentations, the database system including a table containing metadata records 

5 specifying object types including hierarchical organisation object types and media 
object types, and the database also including a table containing content data records, 
each content data record being linked to a metadata record and containing at least one 
value for a parameter applicable to a specific instance of the object type specified in 
the linked metadata record. 

10 

2. A database system as claimed in claim 1, including a primary metadata table 
containing metadata records and a supplementary metadata table containing 
supplementary metadata records, each supplementary metadata record being linked to 
a metadata record and specifying an additional attribute for an object type specified in 

1 5 the linked metadata record, and the database further includes a primary content data 
table containing content data records and a supplementary content data table 
containing supplementary content data records, each supplementary content data 
record being linked to a supplementary metadata record and to a content data record, 
the content data record being linked to the metadata record as a specific instance of 

20 the object type defined in the metadata record, and wherein the supplementary content 
data record contains a value for the additional attribute specified in the linked 
supplementary metadata data record which is applicable to the specific instance of the 
object type specified in the linked metadata record. 

25 3. A database system as claimed in claim 2, wherein an object type link table 
links together records in the primary metadata table. 

4. A database system as claimed in claim 3, wherein a content data link table 
links together records in the primary content data table. 

30 

5. A database system as claimed in claim 2, in combination with an information 
retrieval system which analyses the primary metadata table, the primary content data 
table, the supplementary metadata table and the supplementary data table and 
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provides, for a selected instance of an object, information about that object's attributes 
and relationships with other objects in a hierarchical form. 

6. A database system as claimed in claim 5, wherein an object type link table 
links together records in the primary metadata table and a content data link table links 
together records in the primary content data table, and wherein the information 
retrieval system also analyses the object type link table and the content data link table 
to provide for the selected instance of an object, information about that object's 
relationships with other objects. 

7. A database system as claimed in claim 1 , wherein at least one media object 
type identifies media content. 

8. A database system as claimed in claim 7, wherein the media content is 
selected from text, images, moving images and audio. 

9. A database system as claimed in claim 8 wherein a media object identifying 
media content is linked to a plurality of media objects identifying different formats for 
that content. 

10. A database system as claimed in claim 8, wherein the hierarchical organisation 
object types include subjects and stories. 

11. A database system as claimed in claim 10, wherein the media content and 
hierarchical organisation object types are for use in a media presentation selected 
from a web page, a broadcast and a printed publication. 

12. A database system as claimed in claim 1, wherein at least one hierarchical 
organisation object type defines folders. 

13. A database system for storing information relating to a number of objects of 
various object types, comprising: a first metadata table containing records, each first 
metadata table record specifying an available object type and defining a set of 
attributes relevant to the object type; a first content table containing records, each first 
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content table record being linked to a record in the first metadata table and containing 
data pertaining to an object which is a specific instance of the object type specified in 
the linked record in the first metadata table, the data including a value for at least one 
attribute defined in the linked record in the first metadata table; a second metadata 
5 table containing records, each second metadata table record being linked to a record in 
the first metadata table and defining an additional attribute relevant to the object type 
specified in the linked record in the first metadata table; and a second content table 
containing records, each second content table record being linked to a record in the 
first content table and to a record in the second metadata table and containing a data 
10 value for the additional attribute defined in the linked record in the second metadata 
table which applies to the specific instance of the object in the linked record in the 
first content table. 

14. A database system as claimed in claim 1 3, wherein there is provided an object 
1 5 type link table which links together records in the first metadata table and a content 

data link table which links together records in the first content table. 

1 5. A database system as claimed in claim 1 3 wherein the first metadata table has 
a field for identifying a parent record of an object type record and the first content 

20 table has a field for identifying a parent record of an instance record. 

16. A database system as claimed in claim 14, in combination with an information 
retrieval system running on data processing means which analyses the first metadata 
table, the first content data table, the second metadata table, the second data table, the 

25 object type link table and the content data link table and provides, for a selected 

instance of an object, information about that object's attributes and relationships with 
other objects in a hierarchical form. 

1 7. An information retrieval system running on data processing means, for use 
30 with a database system as claimed in claim 14, which is arranged to analyse the first 

metadata table, the first content data table, the second metadata table, the second data 
table, the object type link table and the content data link table and provides, for a 
selected instance of an object, information about that object's attributes and 
relationships with other objects in a hierarchical structure. 
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18. A computer software product containing instructions which when carried out 
on data processing means will create an information retrieval system for use with a 
database system as claimed in claim 14, which is arranged to analyse the first 
5 metadata table, the first content data table, the second metadata table, the second data 
table, the object type link table and the content data link table and provides, for a 
selected instance of an object, information about that object's attributes and 
relationships with other objects in a hierarchical structure. 

10 19. A computer software product containing instructions which when carried out 
on data processing means will create a database system for storing information 
relating to a number of objects of various object types, comprising: 

a first metadata table for containing a plurality of records of object types, the 
1 5 first metadata table having fields for specifying an available object type and defining a 
set of attributes relevant to the object type; 

a first content table for containing records of specific instances of object types, 
the first content table having fields for containing data pertaining to an object which is 
20 a specific instance of an object type specified in a record in the first metadata table, 
the data including a value for at least one attribute defined for the object type 
specified in the first metadata table; 

the database system being arranged to define a link between a record in the 
25 first content table and the record in the first metadata table; 



a second metadata table for containing records of supplementary metadata, the 
second metadata table record having a field for defining an additional attribute 
relevant to an object type specified in a record in the first metadata table; 

30 

the database system being arranged to define a link between a record in the 
second metadata table and a record in the first metadata table; 

and 
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a second content table for containing records, the second content table having 
a field containing a data value for the additional attribute defined in a record in the 
second metadata table which applies to a specific instance of an object in the first 
5 content table; 

the database system being arranged to define a link between a record in the second 
content table and a record in the second metadata table, and a link between a record in 
the second content table and a record in the first content table. 

10 

20. A computer software product as claimed in claim 19, wherein the database 
created includes an object type link table which links together records in the first 
metadata table and a content data link table which links together records in the first 
content table. 

15 

21 . A computer software product as claimed in claim 19, wherein the first 
metadata table has a field for identifying a parent record of an object type record and 
the first content table has a field for identifying a parent record of an instance record. 

20 22. A method for acquiring and storing media objects and for making the media 
objects available from a hierarchical structure for use in media presentations, 
comprising the steps of : accessing a database for storing information relating to a 
number of objects of various object types, the database comprising a first metadata 
table, a first content table, a second metadata table and a second content table; 

25 entering into the first metadata table object type records, each specifying an object 

type and defining at least one attribute relevant to the object type; in respect of at least 
one object type record in the first metadata table, entering into the second metadata 
table a record linked to the object type record and defining an additional attribute 
relevant to the object type specified in the linked record in the first metadata table; 

30 acquiring data relating to media objects, each of which is a specific instance of an 

object type specified in the linked record in the first metadata table; in respect of each 
media object entering into the first content table a record linked to the associated 
object type record in the first metadata table and containing data pertaining to the 
media object, the data including a value for at least one attribute defined in the linked 
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record in the first metadata table; and in respect of at least one media object entering 
into the second content table a record linked to the media object record in the first 
content table and to the associated object type record in the second metadata table and 
containing a data value for the additional attribute defined in the linked record in the 
second metadata table which applies to the media object in the linked record in the 
first content table; the method including the further step of providing an information 
retrieval system running on data processing means which analyses the first metadata 
table, the first content data table, the second metadata table and the second data table, 
and provides, for a selected instance of an object, information about that object's 
attributes and relationships with other objects in a hierarchical form. 

23. A method as claimed in claim 22, including the step of accessing media 
objects defined in the database using the information retrieval system and creating a 
media presentation using the objects. 

24. A media presentation created by a method as claimed in claim 23. 
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Subject : ObtectStore::meta item 



metajtemjd : (PK) long * 1 
metajtem_parentjd : (FK) long 
metajtem_name : String = Subject 
.description : String = Subject is ... 



Story : ObjectStore::meta item 



metajtemjd : (PK) long = 2 
metajtem_parentjd : (FK) long = 1 
metajtem_name : String = Story 
description : String s Story is ... 



StorvText : Ob?ectStore::meta field 



metajieldjd : (PK)long = 1 
metajtemjd : (FK) long = 2 
name : String = Story Text 
mandatory : boolean = True 
default_value : String 
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Subject : ObjectS<ore::meta jtem, 




Subjectlpstance : ObjectStore::c item 








metajtemjd : (PK) long = 1 
metajtemjsarentjd : (FK) long 
metajtemjiame : String = Subject 
description : String = Subject is ... 




itemjd : (PK) long = 1 
item_parent_id : (FK) long 
metajtemjd : (FK) long = 1 
title : String = Sport 
description : String = Sport is ... 





Story : ObiectStore::meta item 



metajtemjd : (PK) long - 2 
metajtem_parent_id : (FK) long = 1 
metajtemjiame : String = Story 
description : String = Story is ... 



Storvlnsrance : ObiectStore::c item 



itemjd : (PK) long = 2 

item_parentjd : (FK) long = 1 

metajtemjd : (FK) Jong = 2 

title :~String = Sampras Wins At French Open 

description : String 



StorvText : ObiectStore::meta field 



meta Jieldjd : (PK)long * 1 
metajtemjd : (FK) long = 2 
name : String = Story Text 
mandatory : boolean = True 
defauttyalue : String 



StoryTextlnstance : ObjectStoreix field 



field Jd : (PK) long = 1 
itemjd : (FK) long = 2 
metajieldjd : (FK) long » 1 
fleld_value = Full text story 
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Subject : ObiectStore::meta Jtem 



metajtemjd : (PK) long = 1 
metajtemjmrentjd : (FK) long 
metajtemjiame : String = Subject 
description : String = Subject is ... 



Image : ObiectStore::meta item 



metajtemjd : (PK) long = 3 
metajtemjparentjd : (FK) long = 1 
metajtemjiame : String = Image 
description : String = Image is ... 



J 







I 


maaeFilename : ObiectStore::meta field 
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netajieldjd : (PK)long ■ 2 
netajtemjd : (FK) long = 3 
»ame : String = Image Filename 
nandatory : boolean = True 
lefault_value : String 








ImaaeWidth : ObiectStore::meta field 






metajieldjd : (PK)long = 3 
metajtemjd : (FK) long = 3 
name ; String = Image Width 
mandatory : boolean = False 
default_value : String = 0 








ImaaeHeioht : OblectStore::meta field 






metajieldjd : (PK)long = 4 
metajtemjd : (FK) long = 3 
name : String = Image Height 
mandatory : boolean = False 
default_.value : String = 0 








ImaaeCaDtion : ObiectStore::meta field 








metajieldjd : (PK)long = 5 
metajtemjd : (FK) long = 3 
name : String = Image Caption 
mandatory : boolean = False 
defaultj/alue : String 
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Subject : ObiectStore::meta Item 








metajtemjd : (PK) long = 1 
meta_Jtem_parent_id : (FK) long 
metajtemjiame : String = Subject 
description : String = Subject is ... 



Sublectlnstance : ObiectStore::c item 



itemjd : (PK) long = 1 
itemjrarentjd : (FK) long 
metajtem jd : (FK) long = 1 
title : String = Sport 
description : String = Sport is . 



Imagelnstance : ObiectStore::c item 



itemjd : (PK) long = 3 
item_parentjd : (FK) long = 1 
metajtemjd : (FK) long = 3 
title : String = Sampras wins 
description : String = Image description 
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ImaaeFilenamelnstance : ObiectStore::c field 
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netajieldjd : (PK)long = 2 
netajtemjd : (FK) long = 3 
ame : String = Image Filename 
nandatory : boolean = True 
efault_value : String 




field Jd : (PK) long = 2 
item id : (FK) long = 3 
meta Jieldjd : (FK) long = 2 
field_value = sampras.jpg 






















ImaoeWidth : ObiectStore::meta field 




ImaoeWldthlnstance : ObiectStore::c field 


















meta Jieldjd : (PK)long ■ 3 
metajtem Jd : (FK) long = 3 
name : String = Image Width 
mandatory : boolean = False 
default_value : String = 0 


field Jd : (PK) long « 3 
itemjd ; (FK) long = 3 
meta_fieldjd : (FK) long = 3 
field value = 50 










ImaqeHeiaht : ObiectStore::meta field 




ImaqeHeiqhtlnstance : ObiectStore::c field 














meta Jieldjd : (PK)long = 4 
metajtemjd : (FK) long = 3 
name : String = Image Height 
mandatory : boolean = False 
default_value ; String = 0 


fieldJd:(PK) long = 4 
item id : (FK) long = 3 
meta_fie1djd : (FK) long = 4 
field_value = 1 00 














ImaaeCaDtion : ObiectStore::meta field 




ImaqeCaDtionlnstance : ObiectStore::c field 


















meta_fieldjd : (PK)long = 5 
metajtemjd : (FK) long = 3 
name : String = Image Caption 
mandatory : boolean = False 
default_value : String 






field Jd : (PK) long = 5 
item id : (FK) long = 3 
meta Jieldjd : (FK) long = 5 * 
fie!d_value ■ Image caption text 







Image : ObiectStore::meta item 



metajtemjd : (PK) long = 3 
metaJtemjDarentJd : (FK) long = 1 
metajtem_name : String = Image 
description : String = Image is ... 
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metajtemjd : (PK) long = 3 
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metajtem_name : String = Image 
description : String = Image is ... 
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Subiect : ObiectStore::meta item 




Subiectlnstance : ObiectStore::c item 














metajtemjd : (PK) long = 1 
metajtemjDarentJd : (FK) long 
metajtemjiame : String = Subject 
description : String = Subject is ... 


itemjd : (PK) long = 1 
item_parentjd : (FK) long 
metajtemjd : (FK) long = 1 
title : String - Sport 
description : String = Sport is ... 



Story : ObiectStore::meta item 



metajtemjd : (PK) long = 2 
metajtem_parentjd : (FK) long = 1 
metajtemjiame : String = Story 
description : String = Story is ... 



Storvlnstance : ObiectStorerx Item 



itemjd : (PK) long = 2 
item jpa rent Jd : (FK) long = 1 
metajtemjd : (FK) long = 2 
title : String = Sampras Wins at French Open 
description : String 



StorvlmageLInk : ObiectStore::meta item link 



metajtemjd 1 : (PK) long = 2 
metajtemjd2 : (PK) long = 3 



StorvlmaoeLinklnstance : QbiectStore::c item link 



itemjdl : (PK) long = 2 
itemjd2 : (PK) long = 3 





Imaoe : ObiectStore::meta item 






metajtemjd : (PK) long = 3 
metajtemjaarentjd : (FK) long = 1 
metajtemjiame : String = Image 
description : String = Image is ... 



Imaaelnstance : ObiectStorerx item 








itemjd : (PK) long = 3 
item_parentjd : (FK) long = 1 
metajtem^id : (FK) long = 3 
title :"string = Sampras wins 
description : String = Image description 
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DatuPnwidartObtedSlorar.metB Bern 



rrwta^RorTuH : (PK) long ■ 4 
meta Jtem_parer>Ud : (FK) tong 
meta &en\_nwno : Siring » Data Provider 
description : String * Data Pnwtderb .. 



oataSourcoFito ; Obtoctstoronmela Hem 



melajlemjd : (PK) long - 5 
metajtefl\_parentjd : (FK) tang » 4 
mata_aen\_name : String » Data Source File 
description : String ■ Data Source Fee Is ... 



nwtaJtemJd:(PK)tong = 7 
meta_itern_paientW : (FK) long » 5 
meta Jen\_name : String • Data Set 
description: String* Data Setts- 



Drtaliem : obtectstorenmgta Rem 



metajtemjd : (PK) long = 8 
meta_Bern_parom_W : (FK) tong » 7 
meta Rernjiarra : String » Data Item 
"1ng =- Data Bemb 



DatBHeMMaoptnn • ObtectSlMttaTMla l)cni 



meta_len\.H : (PK) long ** 6 
me»a_«em_parenUd : (FK) tong - 5 
meta~aern_name : String = Data Field Mapphg 
description : String ° Data Held Mapping b ... 



RunDatB : ObhctSlorermnla ttett 



metaJieUJd : (PKJtong - 13 
metajtemjd : (FK) long « 7 
name : Strhg ° Run Date 
mandatory : boolean » True 

String 



)npmpgsipon;9biectsiore^nwta frM 



meto_BeJd_ld : (PK)long =10 
mBtaJten\Jd : (FK) long « 6 
name : String a Input PosRton 
mandatory : boolean «» True 
defauB_vatuo : String 



Tvpe;QWwts|ort^meia fatd 



metaJiekUd : (PKJtong = 11 
metajtemjd : (FK) tong =■ 9 
name: Strings Type 
mandatory : boolean ° True 
detau^valua : String 



J p yjpuiposllon : ObledS|gre;rmeta fiaM 



Pata^pb|ertSto^:rnoft feM 



meta Jieldjd : (PKJtong » 14 
metajtemjd : (FK) tong * 8 



defaun_va1ue : String 



metajtaldjd : (PK)tong - 12 
metajtemjd : (FK) tong « 6 
name : String * Output PosRton 
mandatory : boolean = True 
defaulLvalue : String 



rnatajteldjd : (PKJtong = 6 
metajtemjd : (FK) long » 5 
name : Siring ° Source Location 
mandatory : boolean » True 
defoutLvotua : Siring 



nwtaJeld_ld:(PK)tong»7 
metajemjd : (FK) tong «■ 5 
name : String a Source Type 
mandatory : bootoan a True 
deteutLvaJue: string 



Proces^EnflVie ; ptri.gtiSttrcr.mgta fftti 



metajteldjd: (PKJtong- 8 
metajtemjd : (FK) long = S 
name : String ° Process Engine 
mandatory : boolean 
defauR_valuo ■ String 



Refrgsr^rte;pb[ectSlore;:meta fje)fl 



melajaldjd: (PKJtong "9 
metajtemjd : (FK) tong ■ S 
name : Suing ■ Refresh Rate 
mandatory : boolean ° True 
detauB,vafae : String * 0 
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